home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-ifmib-evolution-00.txt < prev    next >
Text File  |  1993-06-07  |  53KB  |  1,624 lines
  1.  
  2.  
  3.           Draft             Interfaces Group Evolution          May 1993
  4.  
  5.  
  6.  
  7.  
  8.  
  9.                    Evolution of the Interfaces Group of MIB-II
  10.  
  11.                                    1 June 1993
  12.  
  13.  
  14.                                  Keith McCloghrie
  15.                                 Hughes LAN Systems
  16.                                    kzm@hls.com
  17.  
  18.                                Frank J. Kastenholz
  19.                                    FTP Software
  20.                                   kasten@ftp.com
  21.  
  22.  
  23.  
  24.           Status of this Memo
  25.  
  26.           This document is an Internet Draft.  Internet Drafts are
  27.           working documents of the Internet Engineering Task Force
  28.           (IETF), its Areas, and its Working Groups.  Note that other
  29.           groups may also distribute working documents as Internet
  30.           Drafts.
  31.  
  32.           Internet Drafts are valid for a maximum of six months and may
  33.           be updated, replaced, or obsoleted by other documents at any
  34.           time.  It is inappropriate to use Internet Drafts as reference
  35.           material or to cite them other than as a "work in progress".
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.           Expires November 1993                                 [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.           Draft             Interfaces Group Evolution          May 1993
  62.  
  63.  
  64.           1.  Introduction
  65.  
  66.           MIB-II [3] is the core set of managed objects defined for use
  67.           by network management of the Internet suite of protocols.
  68.           MIB-II was defined using the SNMPv1 Network Management
  69.           Framework.
  70.  
  71.           This memo discusses the 'interfaces' group of MIB-II,
  72.           especially the experience gained from the definition of
  73.           numerous media-specific MIB modules for use in conjunction
  74.           with the 'interfaces' group for managing various sub-layers
  75.           beneath the internetwork-layer.  It proposes clarifications
  76.           to, and extensions of, the architectural issues within the
  77.           current model used for the 'interfaces' group.
  78.  
  79.           This memo also includes a MIB module.  As well as including
  80.           new experimental MIB definitions to support the architectural
  81.           extensions, this MIB module also re-specifies the 'interfaces'
  82.           group of MIB-II in a manner which is both compliant to the
  83.           SNMPv2 SMI and semantically-identical to the existing SNMPv1-
  84.           based definitions.
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.           Expires November 1993                                 [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.           Draft             Interfaces Group Evolution          May 1993
  120.  
  121.  
  122.           2.  The SNMPv2 Network Management Framework
  123.  
  124.           The SNMPv2 Network Management Framework consists of four major
  125.           components.  They are:
  126.  
  127.           o    RFC 1441 which defines the SMI, the mechanisms used for
  128.                describing and naming objects for the purpose of
  129.                management.
  130.  
  131.           o    RFC 1213 defines MIB-II, the core set of managed objects
  132.                for the Internet suite of protocols.
  133.  
  134.           o    RFC 1445 which defines the administrative and other
  135.                architectural aspects of the framework.
  136.  
  137.           o    RFC 1448 which defines the protocol used for network
  138.                access to managed objects.
  139.  
  140.           The Framework permits new objects to be defined for the
  141.           purpose of experimentation and evaluation.
  142.  
  143.  
  144.           2.1.  Object Definitions
  145.  
  146.           Managed objects are accessed via a virtual information store,
  147.           termed the Management Information Base or MIB.  Objects in the
  148.           MIB are defined using the subset of Abstract Syntax Notation
  149.           One (ASN.1) defined in the SMI.  In particular, each object
  150.           object type is named by an OBJECT IDENTIFIER, an
  151.           administratively assigned name.  The object type together with
  152.           an object instance serves to uniquely identify a specific
  153.           instantiation of the object.  For human convenience, we often
  154.           use a textual string, termed the descriptor, to refer to the
  155.           object type.
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.           Expires November 1993                                 [Page 3]
  173.  
  174.  
  175.  
  176.  
  177.           Draft             Interfaces Group Evolution          May 1993
  178.  
  179.  
  180.           3.  Experience with the Interfaces Group
  181.  
  182.           One of the strengths of internetwork-layer protocols such as
  183.           IP [6] is that they are designed to run over any network
  184.           interface.  In achieving this, IP considers any and all
  185.           protocols it runs over as a single "network interface" layer.
  186.           A similar view is be taken by other internetwork-layer
  187.           protocols.  This concept is represented in MIB-II by the
  188.           'interfaces' group which defines a generic set of managed
  189.           objects such that any network interface can be managed in an
  190.           interface-independent manner through these managed objects.
  191.           The 'interfaces' group provides the means for additional
  192.           managed objects specific to particular types of network
  193.           interface (e.g., a specific medium such as Ethernet) to be
  194.           defined as extensions to the 'interfaces' group for media-
  195.           specific management.  Since the standardization of MIB-II,
  196.           many such media-specific MIB modules have been defined.
  197.  
  198.           Experience in defining these media-specific MIB modules has
  199.           shown that the model defined by MIB-II is too simplistic
  200.           and/or static for some types of media-specific management.  As
  201.           a result, some of these media-specific MIB modules have
  202.           assumed an evolution/loosening of the model.  This memo is a
  203.           proposal to document/standardize the evolution of the model
  204.           and to fill in the gaps caused by that evolution.
  205.  
  206.  
  207.           3.1.  Areas of Clarification/Revision
  208.  
  209.           There are four areas for which experience indicates that
  210.           clarification or revision of the model would be helpful.  The
  211.           next sections discuss these.
  212.  
  213.  
  214.           3.1.1.  Interface Numbering
  215.  
  216.           MIB-II defines an object, ifNumber, whose value represents:
  217.  
  218.                "The number of network interfaces (regardless of their
  219.                current state) present on this system."
  220.  
  221.           Each interface is identified by a unique value of the ifIndex
  222.           object, and the description of ifIndex constrains its value as
  223.           follows:
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.           Expires November 1993                                 [Page 4]
  231.  
  232.  
  233.  
  234.  
  235.           Draft             Interfaces Group Evolution          May 1993
  236.  
  237.  
  238.                "Its value ranges between 1 and the value of ifNumber.
  239.                The value for each interface must remain constant at
  240.                least from one re-initialization of the entity's network
  241.                management system to the next re-initialization."
  242.  
  243.           This constancy requirement on the value of ifIndex for a
  244.           particular interface is vital for efficient management.
  245.           However, an increasing number of devices allow for the dynamic
  246.           addition/removal of network interfaces.  One example of this
  247.           is a dynamic ability to configure the use of SLIP/PPP over a
  248.           character-oriented port.  For such dynamic additions/removals,
  249.           the combination of the constancy requirement and the
  250.           restriction that the value of ifIndex is less than ifNumber is
  251.           problematic.
  252.  
  253.  
  254.           3.1.2.  Interface Sub-Layers
  255.  
  256.           Experience in defining media-specific management information
  257.           has shown the need to distinguish between the multiple sub-
  258.           layers beneath the internetwork-layer.  In addition, there is
  259.           a need to manage these sub-layers in devices (e.g., MAC-layer
  260.           bridges) which are unaware of which, if any, internetwork
  261.           protocols run over these sub-layers.  As such, a model of
  262.           having a single conceptual row in the interfaces table (MIB-
  263.           II's ifTable) represent a whole interface underneath the
  264.           internetwork-layer, and having a single associated media-
  265.           specific MIB module (referenced by the ifSpecific object) is
  266.           too simplistic.  A further problem arises with the value of
  267.           the ifType object which has enumerated values for each type of
  268.           interface.
  269.  
  270.           Consider, for example, an interface with PPP running over an
  271.           HDLC link which uses a RS232-like connector.  Each of these
  272.           sub-layers has its own media-specific MIB module.  If all of
  273.           this is represented by a single conceptual row in the ifTable,
  274.           then an enumerated value for ifType is needed for that
  275.           specific combination, and that row's ifSpecific variable can
  276.           "point" to only one of the three media-specific MIB modules.
  277.           Furthermore, even if there was a convention for deciding which
  278.           MIB module is referenced by ifSpecific then there is still a
  279.           lack of a method to describe the relationship of all the sub-
  280.           layers of the MIB stack.
  281.  
  282.           An associated problem is that of upward and downward
  283.  
  284.  
  285.  
  286.  
  287.  
  288.           Expires November 1993                                 [Page 5]
  289.  
  290.  
  291.  
  292.  
  293.           Draft             Interfaces Group Evolution          May 1993
  294.  
  295.  
  296.           multiplexing of the sub-layers.  An example of upward
  297.           multiplexing is MLP (Multi-Link) which provides load-sharing
  298.           over several serial lines by appearing as a single point-to-
  299.           point link to the sub-layer(s) above.  An example of downward
  300.           multiplexing would be several instances of PPP, each running
  301.           over a Frame Relay virtual circuit, all of which run over the
  302.           same ISDN B channel.  The current MIB structure does not allow
  303.           for these sorts of relationships to be described.
  304.  
  305.  
  306.           3.1.3.  Virtual Circuits
  307.  
  308.           Several of the sub-layers for which media-specific MIB modules
  309.           have been defined are connection oriented (e.g., Frame Relay,
  310.           X.25).  Experience has shown that each effort to define such a
  311.           MIB module revisits the question of whether separate
  312.           conceptual rows in the ifTable are needed for each virtual
  313.           circuit.  Most, if not all, of these efforts to date have
  314.           decided to have all virtual circuits reference a single
  315.           conceptual row in the ifTable.
  316.  
  317.  
  318.           3.1.4.  Bit and Character Oriented Interfaces
  319.  
  320.           RS-232 is an example of a character-oriented sub-layer over
  321.           which (e.g., through use of PPP) IP datagrams can be sent.
  322.           Due to the packet-based nature of many of the objects in the
  323.           ifTable, experience has shown that it is not appropriate to
  324.           have a character-oriented sub-layer represented by a (whole)
  325.           conceptual row in the ifTable.
  326.  
  327.           Experience has also shown that it is sometimes desirable to
  328.           have some management information for bit-oriented interfaces,
  329.           which are similarly difficult to represent by a (whole)
  330.           conceptual row in the ifTable.  For example, to manage the
  331.           channels of a DS1 circuit, where only some of the channels are
  332.           carrying packet-based data.
  333.  
  334.  
  335.           3.2.  Clarifications/Revisions
  336.  
  337.           The following clarifications and/or revisions are proposed.
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.           Expires November 1993                                 [Page 6]
  347.  
  348.  
  349.  
  350.  
  351.           Draft             Interfaces Group Evolution          May 1993
  352.  
  353.  
  354.           3.2.1.  Interface Numbering
  355.  
  356.           One solution to the interface numbering problem would be to
  357.           redefine ifNumber to be the largest value of ifIndex, but the
  358.           utility of such an object is questionable, and such a re-
  359.           definition would require ifNumber to be deprecated.  Thus, an
  360.           improvement would be to deprecate ifNumber and not replace it.
  361.           However, the deprecation of ifNumber would require a change to
  362.           that portion of ifIndex's definition which refers to ifNumber.
  363.           So, since the definition of ifIndex must be changed anyway in
  364.           order to solve the problem, changes to ifNumber do not benefit
  365.           the solution.
  366.  
  367.           The solution adopted in this memo is just to delete the
  368.           requirement that the value of ifIndex must be less than the
  369.           value of ifNumber, and to retain ifNumber with its current
  370.           definition.  It could be argued that this is a change in the
  371.           semantics of ifIndex; however, all existing implementations
  372.           conform to this new definition, and in the interests of not
  373.           requiring changes in existing implementations and in the many
  374.           existing media-specific MIBs, it is proposed that this change
  375.           does not require ifIndex to be deprecated.
  376.  
  377.           This solution also results in the possibility of "holes" in
  378.           the ifTable, i.e., the ifIndex values of conceptual rows in
  379.           the ifTable are not necessarily contiguous, but SNMP's GetNext
  380.           (and SNMPv2's GetBulk) operation easily deals with such holes.
  381.           The value of ifNumber still represents the number of
  382.           conceptual rows, which increases/decreases as new interfaces
  383.           are dynamically added/removed.  The vital constancy
  384.           requirement is met by requiring that after an interface is
  385.           dynamically removed, its ifIndex value is not re-used (by
  386.           another dynamically added interface) until after the following
  387.           re-initialization of the network management system.  This
  388.           avoids the need for a priori assignment of ifIndex values for
  389.           all possible interfaces which might be added dynamically.
  390.  
  391.           Because of the restriction of the value of ifIndex to be less
  392.           than ifNumber, interfaces have been numbered with small
  393.           integer values.  This has led to the ability by humans to use
  394.           the ifIndex values as (somewhat) user-friendly names for
  395.           network interfaces (e.g., "interface number 3").  With the
  396.           relaxation of the restriction on the value of ifIndex, there
  397.           is now the possibility that ifIndex values could be assigned
  398.           as very large numbers (e.g., memory addresses).  Such numbers
  399.  
  400.  
  401.  
  402.  
  403.  
  404.           Expires November 1993                                 [Page 7]
  405.  
  406.  
  407.  
  408.  
  409.           Draft             Interfaces Group Evolution          May 1993
  410.  
  411.  
  412.           would be much less user-friendly.  Therefore, this memo
  413.           recommends that ifIndex values still be assigned as small
  414.           integer values starting at 1, even though the values in use at
  415.           any one time are not necessarily contiguous.  (Note that this
  416.           makes it easy for agents which dynamically add new interfaces,
  417.           to remember which values have been assigned.)
  418.  
  419.  
  420.           3.2.2.  Interface Sub-Layers
  421.  
  422.           One possible but not recommended solution to the problem of
  423.           representing multiple sub-layers would be to retain the
  424.           concept of one conceptual row for all the sub-layers of an
  425.           interface and have each media-specific MIB module identify its
  426.           "superior" and "subordinate" sub-layers through OBJECT
  427.           IDENTIFIER "pointers".  The drawbacks of this scheme are: 1)
  428.           that the superior/subordinate pointers are contained in the
  429.           media-specific MIB modules, and thus, a manager could not
  430.           learn the structure of an interface, without inspecting
  431.           multiple pointers in different MIB modules; this is overly
  432.           complex and only possible if the manager has knowledge of all
  433.           the relevant media-specific MIB modules; 2) current MIB
  434.           modules would all need to be retrofitted with these new
  435.           "pointers"; 3) this scheme does not adequately address the
  436.           problem of upward and downward multiplexing; and 4) enumerated
  437.           values of ifType are needed for each combination of sub-
  438.           layers.
  439.  
  440.           Another possible but not recommended scheme would be to retain
  441.           the concept of one conceptual row for all the sub-layers of an
  442.           interface and have a new separate MIB table to identify the
  443.           "superior" and "subordinate" sub-layers and to contain OBJECT
  444.           IDENTIFIER "pointers" to media-specific MIBs.  Effectively,
  445.           one conceptual row in the ifTable would represent each
  446.           combination of sub-layers between the internetwork-layer and
  447.           the wire.  While this scheme has fewer drawbacks, it would
  448.           deprecate the use of ifSpecific and it still does not support
  449.           downward multiplexing, such as PPP over MLP: since MLP makes
  450.           two (or more) serial lines appear to the layers above as a
  451.           single physical interface, PPP over MLP should appear to the
  452.           internetwork-layer as a single interface; this scheme,
  453.           however, would result in two (or more) conceptual rows in the
  454.           ifTable, both of which the internetwork-layer would run over.
  455.           This scheme also requires enumerated values of ifType for each
  456.           combination of sub-layers.
  457.  
  458.  
  459.  
  460.  
  461.  
  462.           Expires November 1993                                 [Page 8]
  463.  
  464.  
  465.  
  466.  
  467.           Draft             Interfaces Group Evolution          May 1993
  468.  
  469.  
  470.           The solution adopted in this memo is to have an individual
  471.           conceptual row in the ifTable to represent each sub-layer, and
  472.           have a new separate MIB table (the ifStackTable, see section 4
  473.           of this memo) to identify the "superior" and "subordinate"
  474.           sub-layers through INTEGER "pointers" to the appropriate
  475.           conceptual rows in the ifTable.  This solution supports both
  476.           upward and downward multiplexing, allows the ifSpecific
  477.           pointer in each conceptual row of the ifTable to point to the
  478.           media-specific MIB module for that sub-layer, such that the
  479.           new table need only be referenced to obtain information about
  480.           layering, and it only requires enumerated values of ifType for
  481.           each sub-layer, not for combinations of them.  However, it
  482.           does require that the descriptions of some objects in the
  483.           ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts,
  484.           and ifOutUcastPkts) be generalized so as to apply to any sub-
  485.           layer (rather than only to a sub-layer immediately beneath the
  486.           network layer, as at present), plus some (specifically,
  487.           ifSpeed) which need to have appropriate values identified for
  488.           use when a generalized definition does not apply to a
  489.           particular sub-layer.
  490.  
  491.           In addition, this adopted solution makes no requirement that a
  492.           device, in which a sub-layer is instrumented by a conceptual
  493.           row of the ifTable, be aware of whether an internetwork
  494.           protocol runs on top of (i.e., at some layer above) that sub-
  495.           layer.
  496.  
  497.  
  498.           3.2.3.  Virtual Circuits
  499.  
  500.           This memo recommends that, in general, connection-oriented
  501.           sub-layers do not have a conceptual row in the ifTable for
  502.           each virtual circuit.  This avoids the proliferation of
  503.           conceptual rows, especially those which have considerable
  504.           redundant information.  (Note, as a comparison, that
  505.           connection-less sub-layers do not have conceptual rows for
  506.           each remote address.)  There may, however, be circumstances
  507.           under which it is appropriate for a virtual circuit of a
  508.           connection-oriented sub-layer to have its own conceptual row
  509.           in the ifTable; an example of this might be PPP over a Frame
  510.           Relay virtual circuit.  The MIB in section 4 of this memo
  511.           supports such circumstances.
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.           Expires November 1993                                 [Page 9]
  521.  
  522.  
  523.  
  524.  
  525.           Draft             Interfaces Group Evolution          May 1993
  526.  
  527.  
  528.           3.2.4.  Bit and Character Oriented Interfaces
  529.  
  530.           About half the objects in the ifTable are applicable to every
  531.           type of interface: packet-oriented, character-oriented, and
  532.           bit-oriented.  Of the other half, two are applicable to both
  533.           character-oriented and packet-oriented interfaces, and the
  534.           rest are applicable only to packet-oriented interfaces.  Thus,
  535.           while it is desirable for consistency to be able to represent
  536.           any/all types of interfaces in the ifTable, it is not possible
  537.           to implement the full ifTable for bit- and character-oriented
  538.           sub-layers.
  539.  
  540.           One possible but not recommended solution to this problem
  541.           would be to split the ifTable into two (or more) new MIB
  542.           tables, one of which would contain objects that are relevant
  543.           only to packet-oriented interfaces (e.g. PPP), and another
  544.           that may be used by all interfaces.  This is highly
  545.           undesirable since it would require changes in every agent
  546.           implementing the ifTable (i.e., just about every existing SNMP
  547.           agent).
  548.  
  549.           The solution adopted in this memo builds upon the fact that
  550.           compliance statements in SNMPv2 (in contrast to SNMPv1) refer
  551.           to object groups, where object groups are explicitly defined
  552.           by listing the objects they contain.  Thus, in SNMPv2,
  553.           multiple compliance statements can be specified, one for all
  554.           interfaces and additional ones for specific types of
  555.           interfaces.  The separate compliance statements can be based
  556.           on separate object groups, where the object group for all
  557.           interfaces can contain only those objects from the ifTable
  558.           which are appropriate for every type of interfaces.  Using
  559.           this solution, every sub-layer can have its own conceptual row
  560.           in the ifTable.
  561.  
  562.           Thus, the following section contains definitions of the
  563.           objects of the existing 'interfaces' group of MIB-II, in a
  564.           manner which is both SNMPv2-compliant and semantically-
  565.           equivalent to the existing MIB-II definitions.  With
  566.           equivalent semantics, and with the BER ("on the wire")
  567.           encodings unchanged, these definitions retain the same OBJECT
  568.           IDENTIFIER values as assigned by MIB-II.  Thus, no rewrite of
  569.           existing agents is required.
  570.  
  571.           Three new object groups are defined: the ifGeneralGroup
  572.           containing those objects applicable to all types of network
  573.  
  574.  
  575.  
  576.  
  577.  
  578.           Expires November 1993                                [Page 10]
  579.  
  580.  
  581.  
  582.  
  583.           Draft             Interfaces Group Evolution          May 1993
  584.  
  585.  
  586.           interfaces; the ifCharacterGroup containing those objects
  587.           applicable to character-oriented (but not packet-oriented)
  588.           network interfaces; and the ifPacketGroup containing those
  589.           objects applicable only to packet-oriented network interfaces.
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.           Expires November 1993                                [Page 11]
  637.  
  638.  
  639.  
  640.  
  641.           Draft             Interfaces Group Evolution          May 1993
  642.  
  643.  
  644.           4.  Definitions
  645.  
  646.           IF-MIB DEFINITIONS ::= BEGIN
  647.  
  648.           IMPORTS
  649.               MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
  650.               Integer32, TimeTicks, experimental       FROM SNMPv2-SMI
  651.               DisplayString, PhysAddress, RowStatus    FROM SNMPv2-TC
  652.               MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
  653.               mib-2, interfaces                        FROM RFC-1213;
  654.  
  655.  
  656.           -- combining the experimental parts of this MIB with the
  657.           -- existing ifExtensions MIB (RFC 1229) should be considered.
  658.           -- ifExtensions is defined in RFC 1239 as { mib-2 12 }
  659.  
  660.           ifMIB MODULE-IDENTITY
  661.               LAST-UPDATED "9305262355Z"
  662.               ORGANIZATION "IETF Interfaces MIB Working Group"
  663.               CONTACT-INFO
  664.                       "   Keith McCloghrie
  665.                           Hughes LAN Systems
  666.                           1225 Charleston Road
  667.                           Mountain View, Ca. 94043
  668.  
  669.                           Tel: 415-966-7934
  670.                           Fax: 415-966-7980
  671.                           E-mail: kzm@hls.com."
  672.               DESCRIPTION
  673.                       "The MIB module to describe generic objects for
  674.                       network interface sub-layers.  This MIB is an
  675.                       updated version of MIB-II's ifTable."
  676.               ::= { experimental xx }
  677.  
  678.           ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.           Expires November 1993                                [Page 12]
  695.  
  696.  
  697.  
  698.  
  699.           Draft             Interfaces Group Evolution          May 1993
  700.  
  701.  
  702.           -- the Interfaces group
  703.  
  704.           ifNumber  OBJECT-TYPE
  705.               SYNTAX      Integer32
  706.               MAX-ACCESS  read-only
  707.               STATUS      current
  708.               DESCRIPTION
  709.                       "The number of network interfaces (regardless of
  710.                       their current state) present on this system."
  711.               ::= { interfaces 1 }
  712.  
  713.  
  714.           -- the Interfaces table
  715.  
  716.           -- The Interfaces table contains information on the entity's
  717.           -- interfaces.  Each sub-layer below the internetwork-layer
  718.           -- of a network interface is considered to be an interface.
  719.  
  720.           ifTable OBJECT-TYPE
  721.               SYNTAX      SEQUENCE OF IfEntry
  722.               MAX-ACCESS  not-accessible
  723.               STATUS      current
  724.               DESCRIPTION
  725.                       "A list of interface entries.  The number of
  726.                       entries is given by the value of ifNumber."
  727.               ::= { interfaces 2 }
  728.  
  729.           ifEntry OBJECT-TYPE
  730.               SYNTAX      IfEntry
  731.               MAX-ACCESS  not-accessible
  732.               STATUS      current
  733.               DESCRIPTION
  734.                       "An entry containing management information
  735.                       applicable to a particular interface."
  736.               INDEX   { ifIndex }
  737.               ::= { ifTable 1 }
  738.  
  739.           IfEntry ::=
  740.               SEQUENCE {
  741.                   ifIndex             Integer32,
  742.                   ifDescr             DisplayString,
  743.                   ifType              INTEGER,
  744.                   ifMtu               Integer32,
  745.                   ifSpeed             Gauge32,
  746.                   ifPhysAddress       PhysAddress,
  747.  
  748.  
  749.  
  750.  
  751.  
  752.           Expires November 1993                                [Page 13]
  753.  
  754.  
  755.  
  756.  
  757.           Draft             Interfaces Group Evolution          May 1993
  758.  
  759.  
  760.                   ifAdminStatus       INTEGER,
  761.                   ifOperStatus        INTEGER,
  762.                   ifLastChange        TimeTicks,
  763.                   ifInOctets          Counter32,
  764.                   ifInUcastPkts       Counter32,
  765.                   ifInNUcastPkts      Counter32,
  766.                   ifInDiscards        Counter32,
  767.                   ifInErrors          Counter32,
  768.                   ifInUnknownProtos   Counter32,
  769.                   ifOutOctets         Counter32,
  770.                   ifOutUcastPkts      Counter32,
  771.                   ifOutNUcastPkts     Counter32,
  772.                   ifOutDiscards       Counter32,
  773.                   ifOutErrors         Counter32,
  774.                   ifOutQLen           Gauge32,
  775.                   ifSpecific          OBJECT IDENTIFIER
  776.               }
  777.  
  778.           ifIndex OBJECT-TYPE
  779.               SYNTAX      Integer32
  780.               MAX-ACCESS  read-only
  781.               STATUS      current
  782.               DESCRIPTION
  783.                       "A unique value, greater than zero, for each
  784.                       interface.  It is recommended that values are
  785.                       assigned contiguously starting from 1.  The value
  786.                       for each interface sub-layer must remain constant
  787.                       at least from one re-initialization of the
  788.                       entity's network management system to the next
  789.                       re-initialization."
  790.               ::= { ifEntry 1 }
  791.  
  792.           ifDescr OBJECT-TYPE
  793.               SYNTAX      DisplayString (SIZE (0..255))
  794.               MAX-ACCESS  read-only
  795.               STATUS      current
  796.               DESCRIPTION
  797.                       "A textual string containing information about the
  798.                       interface.  This string should include the name of
  799.                       the manufacturer, the product name and the version
  800.                       of the hardware interface."
  801.               ::= { ifEntry 2 }
  802.  
  803.           ifType OBJECT-TYPE
  804.               SYNTAX  INTEGER {
  805.  
  806.  
  807.  
  808.  
  809.  
  810.           Expires November 1993                                [Page 14]
  811.  
  812.  
  813.  
  814.  
  815.           Draft             Interfaces Group Evolution          May 1993
  816.  
  817.  
  818.                           other(1),          -- none of the following
  819.                           regular1822(2),
  820.                           hdh1822(3),
  821.                           ddn-x25(4),
  822.                           rfc877-x25(5),
  823.                           ethernet-csmacd(6),
  824.                           iso88023-csmacd(7),
  825.                           iso88024-tokenBus(8),
  826.                           iso88025-tokenRing(9),
  827.                           iso88026-man(10),
  828.                           starLan(11),
  829.                           proteon-10Mbit(12),
  830.                           proteon-80Mbit(13),
  831.                           hyperchannel(14),
  832.                           fddi(15),
  833.                           lapb(16),
  834.                           sdlc(17),
  835.                           ds1(18),           -- T-1
  836.                           e1(19),            -- european equiv. of T-1
  837.                           basicISDN(20),
  838.                           primaryISDN(21),   -- proprietary serial
  839.                           propPointToPointSerial(22),
  840.                           ppp(23),
  841.                           softwareLoopback(24),
  842.                           eon(25),            -- CLNP over IP [11]
  843.                           ethernet-3Mbit(26),
  844.                           nsip(27),           -- XNS over IP
  845.                           slip(28),           -- generic SLIP
  846.                           ultra(29),          -- ULTRA technologies
  847.                           ds3(30),            -- T-3
  848.                           sip(31),            -- SMDS
  849.                           frame-relay(32)
  850.                       }
  851.               MAX-ACCESS  read-only
  852.               STATUS      current
  853.               DESCRIPTION
  854.                       "The type of interface."
  855.               ::= { ifEntry 3 }
  856.  
  857.           ifMtu OBJECT-TYPE
  858.               SYNTAX      Integer32
  859.               MAX-ACCESS  read-only
  860.               STATUS      current
  861.               DESCRIPTION
  862.                       "The size of the largest datagram which can be
  863.  
  864.  
  865.  
  866.  
  867.  
  868.           Expires November 1993                                [Page 15]
  869.  
  870.  
  871.  
  872.  
  873.           Draft             Interfaces Group Evolution          May 1993
  874.  
  875.  
  876.                       sent/received on the interface, specified in
  877.                       octets.  For interfaces that are used for
  878.                       transmitting network datagrams, this is the size
  879.                       of the largest network datagram that can be sent
  880.                       on the interface."
  881.               ::= { ifEntry 4 }
  882.  
  883.           ifSpeed OBJECT-TYPE
  884.               SYNTAX      Gauge32
  885.               MAX-ACCESS  read-only
  886.               STATUS      current
  887.               DESCRIPTION
  888.                       "An estimate of the interface's current bandwidth
  889.                       in bits per second.  For interfaces which do not
  890.                       vary in bandwidth or for those where no accurate
  891.                       estimation can be made, this object should contain
  892.                       the nominal bandwidth.  For a sub-layer which has
  893.                       no concept of bandwidth, this object should be
  894.                       zero."
  895.               ::= { ifEntry 5 }
  896.  
  897.           ifPhysAddress OBJECT-TYPE
  898.               SYNTAX      PhysAddress
  899.               MAX-ACCESS  read-only
  900.               STATUS      current
  901.               DESCRIPTION
  902.                       "The interface's address at its protocol sub-
  903.                       layer.  For interfaces which do not have such an
  904.                       address (e.g., a serial line), this object should
  905.                       contain an octet string of zero length."
  906.               ::= { ifEntry 6 }
  907.  
  908.           ifAdminStatus OBJECT-TYPE
  909.               SYNTAX  INTEGER {
  910.                           up(1),       -- ready to pass packets
  911.                           down(2),
  912.                           testing(3)   -- in some test mode
  913.                       }
  914.               MAX-ACCESS  read-write
  915.               STATUS      current
  916.               DESCRIPTION
  917.                       "The desired state of the interface.  The
  918.                       testing(3) state indicates that no operational
  919.                       packets can be passed."
  920.               ::= { ifEntry 7 }
  921.  
  922.  
  923.  
  924.  
  925.  
  926.           Expires November 1993                                [Page 16]
  927.  
  928.  
  929.  
  930.  
  931.           Draft             Interfaces Group Evolution          May 1993
  932.  
  933.  
  934.           ifOperStatus OBJECT-TYPE
  935.               SYNTAX  INTEGER {
  936.                           up(1),       -- ready to pass packets
  937.                           down(2),
  938.                           testing(3)   -- in some test mode
  939.                       }
  940.               MAX-ACCESS  read-only
  941.               STATUS      current
  942.               DESCRIPTION
  943.                       "The current operational state of the interface.
  944.                       The testing(3) state indicates that no operational
  945.                       packets can be passed."
  946.               ::= { ifEntry 8 }
  947.  
  948.           ifLastChange OBJECT-TYPE
  949.               SYNTAX      TimeTicks
  950.               MAX-ACCESS  read-only
  951.               STATUS      current
  952.               DESCRIPTION
  953.                       "The value of sysUpTime at the time the interface
  954.                       entered its current operational state.  If the
  955.                       current state was entered prior to the last re-
  956.                       initialization of the local network management
  957.                       subsystem, then this object contains a zero
  958.                       value."
  959.               ::= { ifEntry 9 }
  960.  
  961.           ifInOctets OBJECT-TYPE
  962.               SYNTAX      Counter32
  963.               MAX-ACCESS  read-only
  964.               STATUS      current
  965.               DESCRIPTION
  966.                       "The total number of octets received on the
  967.                       interface, including framing characters."
  968.               ::= { ifEntry 10 }
  969.  
  970.           ifInUcastPkts OBJECT-TYPE
  971.               SYNTAX      Counter32
  972.               MAX-ACCESS  read-only
  973.               STATUS      current
  974.               DESCRIPTION
  975.                       "The number of packets, delivered by this sub-
  976.                       layer to a higher-layer protocol, which were not
  977.                       addressed to a multicast or broadcast address at
  978.                       this sub-layer."
  979.  
  980.  
  981.  
  982.  
  983.  
  984.           Expires November 1993                                [Page 17]
  985.  
  986.  
  987.  
  988.  
  989.           Draft             Interfaces Group Evolution          May 1993
  990.  
  991.  
  992.               ::= { ifEntry 11 }
  993.  
  994.           ifInNUcastPkts OBJECT-TYPE
  995.               SYNTAX  Counter32
  996.               MAX-ACCESS  read-only
  997.               STATUS      current
  998.               DESCRIPTION
  999.                       "The number of packets, delivered by this sub-
  1000.                       layer to a higher-layer protocol, which were
  1001.                       addressed to a multicast or broadcast address at
  1002.                       this sub-layer."
  1003.               ::= { ifEntry 12 }
  1004.  
  1005.           ifInDiscards OBJECT-TYPE
  1006.                   SYNTAX  Counter32
  1007.               MAX-ACCESS  read-only
  1008.               STATUS      current
  1009.               DESCRIPTION
  1010.                       "The number of inbound packets which were chosen
  1011.                       to be discarded even though no errors had been
  1012.                       detected to prevent their being deliverable to a
  1013.                       higher-layer protocol.  One possible reason for
  1014.                       discarding such a packet could be to free up
  1015.                       buffer space."
  1016.               ::= { ifEntry 13 }
  1017.  
  1018.           ifInErrors OBJECT-TYPE
  1019.               SYNTAX      Counter32
  1020.               MAX-ACCESS  read-only
  1021.               STATUS      current
  1022.               DESCRIPTION
  1023.                       "The number of inbound packets that contained
  1024.                       errors preventing them from being deliverable to a
  1025.                       higher-layer protocol."
  1026.               ::= { ifEntry 14 }
  1027.  
  1028.           ifInUnknownProtos OBJECT-TYPE
  1029.               SYNTAX      Counter32
  1030.               MAX-ACCESS  read-only
  1031.               STATUS      current
  1032.               DESCRIPTION
  1033.                       "The number of packets received via the interface
  1034.                       which were discarded because of an unknown or
  1035.                       unsupported protocol."
  1036.               ::= { ifEntry 15 }
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.           Expires November 1993                                [Page 18]
  1043.  
  1044.  
  1045.  
  1046.  
  1047.           Draft             Interfaces Group Evolution          May 1993
  1048.  
  1049.  
  1050.           ifOutOctets OBJECT-TYPE
  1051.               SYNTAX      Counter32
  1052.               MAX-ACCESS  read-only
  1053.               STATUS      current
  1054.               DESCRIPTION
  1055.                       "The total number of octets transmitted out of the
  1056.                       interface, including framing characters."
  1057.               ::= { ifEntry 16 }
  1058.  
  1059.           ifOutUcastPkts OBJECT-TYPE
  1060.               SYNTAX      Counter32
  1061.               MAX-ACCESS  read-only
  1062.               STATUS      current
  1063.               DESCRIPTION
  1064.                       "The total number of packets that higher-level
  1065.                       protocols requested be transmitted, and which were
  1066.                       not addressed to a multicast or broadcast address
  1067.                       at this sub-layer, including those that were
  1068.                       discarded or not sent."
  1069.               ::= { ifEntry 17 }
  1070.  
  1071.           ifOutNUcastPkts OBJECT-TYPE
  1072.               SYNTAX      Counter32
  1073.               MAX-ACCESS  read-only
  1074.               STATUS      current
  1075.               DESCRIPTION
  1076.                       "The total number of packets that higher-level
  1077.                       protocols requested be transmitted, and which were
  1078.                       addressed to a multicast or broadcast address at
  1079.                       this sub-layer, including those that were
  1080.                       discarded or not sent."
  1081.               ::= { ifEntry 18 }
  1082.  
  1083.           ifOutDiscards OBJECT-TYPE
  1084.               SYNTAX      Counter32
  1085.               MAX-ACCESS  read-only
  1086.               STATUS      current
  1087.               DESCRIPTION
  1088.                       "The number of outbound packets which were chosen
  1089.                       to be discarded even though no errors had been
  1090.                       detected to prevent their being transmitted.  One
  1091.                       possible reason for discarding such a packet could
  1092.                       be to free up buffer space."
  1093.               ::= { ifEntry 19 }
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.           Expires November 1993                                [Page 19]
  1101.  
  1102.  
  1103.  
  1104.  
  1105.           Draft             Interfaces Group Evolution          May 1993
  1106.  
  1107.  
  1108.           ifOutErrors OBJECT-TYPE
  1109.               SYNTAX      Counter32
  1110.               MAX-ACCESS  read-only
  1111.               STATUS      current
  1112.               DESCRIPTION
  1113.                       "The number of outbound packets that could not be
  1114.                       transmitted because of errors."
  1115.               ::= { ifEntry 20 }
  1116.  
  1117.           ifOutQLen OBJECT-TYPE
  1118.               SYNTAX      Gauge32
  1119.               MAX-ACCESS  read-only
  1120.               STATUS      current
  1121.               DESCRIPTION
  1122.                       "The length of the output packet queue (in
  1123.                       packets)."
  1124.               ::= { ifEntry 21 }
  1125.  
  1126.           ifSpecific OBJECT-TYPE
  1127.               SYNTAX      OBJECT IDENTIFIER
  1128.               MAX-ACCESS  read-only
  1129.               STATUS      current
  1130.               DESCRIPTION
  1131.                       "A reference to MIB definitions specific to the
  1132.                       particular media being used to realize the
  1133.                       interface.  For example, if the interface is
  1134.                       realized by an ethernet, then the value of this
  1135.                       object refers to a document defining objects
  1136.                       specific to ethernet.  If this information is not
  1137.                       present, its value should be set to the OBJECT
  1138.                       IDENTIFIER { 0 0 }, which is a syntactically valid
  1139.                       object identifier, and any conformant
  1140.                       implementation of ASN.1 and BER must be able to
  1141.                       generate and recognize this value."
  1142.               ::= { ifEntry 22 }
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.           Expires November 1993                                [Page 20]
  1159.  
  1160.  
  1161.  
  1162.  
  1163.           Draft             Interfaces Group Evolution          May 1993
  1164.  
  1165.  
  1166.           --
  1167.           --           The Interface Stack Group
  1168.           --
  1169.           -- Implementation of this group is mandatory for all systems
  1170.  
  1171.           ifStackTable  OBJECT-TYPE
  1172.                SYNTAX        SEQUENCE OF IfStackEntry
  1173.                MAX-ACCESS    not-accessible
  1174.                STATUS        current
  1175.                DESCRIPTION
  1176.                       "The table containing information on the
  1177.                       relationships between the multiple sub-layers of
  1178.                       network interfaces.  In particular, it contains
  1179.                       information on which sub-layers run 'on top of'
  1180.                       which other sub-layers.  Each sub-layer
  1181.                       corresponds to a conceptual row in the ifTable."
  1182.                ::= { ifMIBObjects 1 }
  1183.  
  1184.  
  1185.           ifStackEntry  OBJECT-TYPE
  1186.                SYNTAX        IfStackEntry
  1187.                MAX-ACCESS    not-accessible
  1188.                STATUS        current
  1189.                DESCRIPTION
  1190.                       "Information on a particular relationship between
  1191.                       two sub-layers, specifying that one sub-layer runs
  1192.                       on 'top' of the other sub-layer.  Each sub-layer
  1193.                       corresponds to a conceptual row in the ifTable."
  1194.                INDEX { ifStackHigherLayer, ifStackLowerLayer }
  1195.                ::= { ifStackTable 1 }
  1196.  
  1197.  
  1198.           IfStackEntry ::=
  1199.               SEQUENCE {
  1200.                   ifStackHigherLayer  Integer32,
  1201.                   ifStackLowerLayer   Integer32,
  1202.                   ifStackStatus       RowStatus
  1203.                }
  1204.  
  1205.  
  1206.           ifStackHigherLayer  OBJECT-TYPE
  1207.                SYNTAX        Integer32
  1208.                MAX-ACCESS    not-accessible
  1209.                STATUS        current
  1210.                DESCRIPTION
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.           Expires November 1993                                [Page 21]
  1217.  
  1218.  
  1219.  
  1220.  
  1221.           Draft             Interfaces Group Evolution          May 1993
  1222.  
  1223.  
  1224.                       "The value of ifIndex corresponding to the higher
  1225.                       sub-layer of the relationship, i.e., the sub-layer
  1226.                       which runs on 'top' of the sub-layer identified by
  1227.                       the corresponding instance of ifStackLowerLayer.
  1228.                       If there is no higher sub-layer (below the
  1229.                       internetwork layer), then this object has the
  1230.                       value 0."
  1231.                ::= { ifStackEntry 1 }
  1232.  
  1233.  
  1234.           ifStackLowerLayer  OBJECT-TYPE
  1235.                SYNTAX        Integer32
  1236.                MAX-ACCESS    not-accessible
  1237.                STATUS        current
  1238.                DESCRIPTION
  1239.                       "The value of ifIndex corresponding to the lower
  1240.                       sub-layer of the relationship, i.e., the sub-layer
  1241.                       which runs 'below' the sub-layer identified by the
  1242.                       corresponding instance of ifStackHigherLayer.  If
  1243.                       there is no lower sub-layer, then this object has
  1244.                       the value 0."
  1245.                ::= { ifStackEntry 2 }
  1246.  
  1247.  
  1248.           ifStackStatus  OBJECT-TYPE
  1249.               SYNTAX         RowStatus
  1250.               MAX-ACCESS     read-write
  1251.               STATUS         current
  1252.               DESCRIPTION
  1253.                       "The status of the relationship between two sub-
  1254.                       layers.
  1255.  
  1256.                       Changing the value of this object from "active" to
  1257.                       "notInService" or "destroy" will likely have
  1258.                       consequences up and down the interface stack.
  1259.                       Thus, write access to this object is likely to be
  1260.                       inappropriate for some types of interfaces, and
  1261.                       many implementations will choose not to support
  1262.                       write-access for any type of interface."
  1263.               ::= { ifStackEntry 3 }
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.           Expires November 1993                                [Page 22]
  1275.  
  1276.  
  1277.  
  1278.  
  1279.           Draft             Interfaces Group Evolution          May 1993
  1280.  
  1281.  
  1282.           -- conformance information
  1283.  
  1284.           ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
  1285.  
  1286.           ifGroups      OBJECT IDENTIFIER ::= { ifConformance 1 }
  1287.           ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
  1288.  
  1289.  
  1290.           -- compliance statements
  1291.  
  1292.           ifCompliance MODULE-COMPLIANCE
  1293.               STATUS  current
  1294.               DESCRIPTION
  1295.                       "The compliance statement for SNMPv2 entities
  1296.                       which have network interfaces."
  1297.  
  1298.               MODULE  -- this module
  1299.                   MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
  1300.  
  1301.                   GROUP       ifCharacterGroup
  1302.                   DESCRIPTION
  1303.                       "This group is mandatory only for those network
  1304.                       interfaces which are character-oriented or
  1305.                       packet-oriented."
  1306.  
  1307.                   GROUP       ifPacketGroup
  1308.                   DESCRIPTION
  1309.                       "This group is mandatory only for those network
  1310.                       interfaces which are packet-oriented."
  1311.  
  1312.                   OBJECT      ifStackStatus
  1313.                   SYNTAX      INTEGER { active(1) } -- subset of RowStatus
  1314.                   MIN-ACCESS  read-only
  1315.                   DESCRIPTION
  1316.                       "Write access is not required, and only one of the
  1317.                       six enumerated values for the RowStatus textual
  1318.                       convention need be supported, specifically:
  1319.                       active(1)."
  1320.               ::= { ifCompliances 1 }
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.           Expires November 1993                                [Page 23]
  1333.  
  1334.  
  1335.  
  1336.  
  1337.           Draft             Interfaces Group Evolution          May 1993
  1338.  
  1339.  
  1340.           -- units of conformance
  1341.  
  1342.           ifGeneralGroup    OBJECT-GROUP
  1343.               OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
  1344.                         ifAdminStatus, ifOperStatus, ifLastChange,
  1345.                         ifSpecific }
  1346.               STATUS  current
  1347.               DESCRIPTION
  1348.                       "A collection of objects providing information
  1349.                       applicable to all network interfaces."
  1350.               ::= { ifGroups 1 }
  1351.  
  1352.           ifCharacterGroup    OBJECT-GROUP
  1353.               OBJECTS { ifInOctets, ifOutOctets }
  1354.               STATUS  current
  1355.               DESCRIPTION
  1356.                       "A collection of objects providing information
  1357.                       specific to packet-oriented or character-oriented
  1358.                       network interfaces."
  1359.               ::= { ifGroups 2 }
  1360.  
  1361.           ifPacketGroup    OBJECT-GROUP
  1362.               OBJECTS { ifMtu, ifInUcastPkts, ifInNUcastPkts,
  1363.                         ifInDiscards, ifInErrors, ifInUnknownProtos,
  1364.                         ifOutUcastPkts, ifOutNUcastPkts, ifOutDiscards,
  1365.                         ifOutErrors, ifOutQLen }
  1366.               STATUS  current
  1367.               DESCRIPTION
  1368.                       "A collection of objects providing information
  1369.                       specific to packet-oriented network interfaces."
  1370.               ::= { ifGroups 3 }
  1371.  
  1372.           ifStackGroup    OBJECT-GROUP
  1373.               OBJECTS { ifStackStatus }
  1374.               STATUS  current
  1375.               DESCRIPTION
  1376.                       "A collection of objects providing information on
  1377.                       the layering of MIB-II interfaces."
  1378.               ::= { ifGroups 4 }
  1379.  
  1380.           END
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.           Expires November 1993                                [Page 24]
  1391.  
  1392.  
  1393.  
  1394.  
  1395.           Draft             Interfaces Group Evolution          May 1993
  1396.  
  1397.  
  1398.           5.  Acknowledgements
  1399.  
  1400.           The proposals in this memo are the result of conversations and
  1401.           discussions with many people, including at least the
  1402.           following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy
  1403.           Greene, Marshall Rose, Kaj Tesink, and Dean Throop.  However,
  1404.           it does not necessarily represent any consensus among the
  1405.           above-mentioned.
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.           Expires November 1993                                [Page 25]
  1449.  
  1450.  
  1451.  
  1452.  
  1453.           Draft             Interfaces Group Evolution          May 1993
  1454.  
  1455.  
  1456.           6.  References
  1457.  
  1458.           [1]  M.T. Rose and K. McCloghrie, Structure and Identification
  1459.                of Management Information for TCP/IP-based internets,
  1460.                Request for Comments 1155.  (May, 1990).
  1461.  
  1462.  
  1463.           [2]  M. Rose and K. McCloghrie, Editors, Concise MIB
  1464.                Definitions, RFC 1212, March 1991.
  1465.  
  1466.  
  1467.           [3]  K. McCloghrie and M.T. Rose, Management Information Base
  1468.                for Network Management of TCP/IP-based internets - MIB-2,
  1469.                Request for Comments 1213.  (March, 1991).
  1470.  
  1471.  
  1472.           [4]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
  1473.                Simple Network Management Protocol, Request for Comments
  1474.                1157.  (May, 1990).
  1475.  
  1476.  
  1477.           [5]  International Organization for Standardization,
  1478.                Information processing systems - Open Systems
  1479.                Interconnection - Specification of Abstract Syntax
  1480.                Notation One (ASN.1), International Standard 8824,
  1481.                (December, 1987).
  1482.  
  1483.  
  1484.           [6]  J. Postel, Internet Protocol, RFC791, September 1981.
  1485.  
  1486.  
  1487.           [7]  K. McCloghrie, Extensions to the Generic-Interface MIB,
  1488.                RFC1229, May 1991.
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.           Expires November 1993                                [Page 26]
  1507.  
  1508.  
  1509.  
  1510.  
  1511.           Draft             Interfaces Group Evolution          May 1993
  1512.  
  1513.  
  1514.           7.  Security Considerations
  1515.  
  1516.           Security issues are not discussed in this memo.
  1517.  
  1518.  
  1519.           8.  Authors' Address
  1520.  
  1521.                Keith McCloghrie
  1522.                Hughes LAN Systems
  1523.                1225 Charleston Rd,
  1524.                Mountain View, Ca 94043
  1525.                415-966-7934
  1526.                kzm@hls.com
  1527.  
  1528.                Frank Kastenholz
  1529.                FTP Software
  1530.                2 High Street
  1531.                North Andover, Mass. USA 01845
  1532.                (508)685-4000
  1533.                kasten@ftp.com
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.           Expires November 1993                                [Page 27]
  1565.  
  1566.  
  1567.  
  1568.  
  1569.           Draft             Interfaces Group Evolution          May 1993
  1570.  
  1571.  
  1572.           Table of Contents
  1573.  
  1574.  
  1575.           1 Introduction ..........................................    2
  1576.           2 The SNMPv2 Network Management Framework ...............    3
  1577.           2.1 Object Definitions ..................................    3
  1578.           3 Experience with the Interfaces Group ..................    4
  1579.           3.1 Areas of Clarification/Revision .....................    4
  1580.           3.1.1 Interface Numbering ...............................    4
  1581.           3.1.2 Interface Sub-Layers ..............................    5
  1582.           3.1.3 Virtual Circuits ..................................    6
  1583.           3.1.4 Bit and Character Oriented Interfaces .............    6
  1584.           3.2 Clarifications/Revisions ............................    6
  1585.           3.2.1 Interface Numbering ...............................    7
  1586.           3.2.2 Interface Sub-Layers ..............................    8
  1587.           3.2.3 Virtual Circuits ..................................    9
  1588.           3.2.4 Bit and Character Oriented Interfaces .............   10
  1589.           4 Definitions ...........................................   12
  1590.           5 Acknowledgements ......................................   25
  1591.           6 References ............................................   26
  1592.           7 Security Considerations ...............................   27
  1593.           8 Authors' Address ......................................   27
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.           Expires November 1993                                [Page 28]
  1623.  
  1624.